Template talk:Physical constants/Archive 1

Archive 1

Bad idea

Copied from Wikipedia talk:WikiProject Measurement#A template for physical constants?

I'm really not a fan of having a template handle physical constants. Consider a passage like 2 × μ_N = 2 × 5.05078353(11)×10⁻²⁷ J/T =1.010156706(22)×10⁻²⁶ J/T, with the underlined part being handled through the template. The nuclear magneton then get an update in 2012 to 5.05078351(5)×10⁻²⁷ J/T, and the article automatically becomes updated to 2 × μ_N = 2 × 5.05078351(5)×10⁻²⁷ J/T = 1.010156706(22)×10⁻²⁶ J/T, which is wrong. Or alternatively, consider a passage such as The 2010 CODATA value for the nuclear magneton is μ_N = 5.05078353(11)×10⁻²⁷ J/T. In 2012, the template gets an update, but not the article, and this reads The 2010 CODATA value for the nuclear magneton is μ_N = 5.05078351(5)×10⁻²⁷ J/T, which is again wrong. Template like these seem to "simplify" maintenance at first, but really all it does is create more work to make sure the use of these templates don't introduce falsehoods in articles. Headbomb {talk / contribs / physics / books} 01:58, 20 June 2011 (UTC)

Theoretically, this could be mitigated by another template to run+display such calculations. But that could get overcomplicated syntax-wise. Curse ye, MediaWiki feature limitations! Where's wikidata when we need it... --Cybercobra (talk) 02:08, 20 June 2011 (UTC)

Yeah, that'd be awesome, but it's not gonna happen in at least half a dozen years, I think. OTOH, those calculations which are likely to be used in a non-trivial number of articles (say, the reciprocal of the fine structure constant) could be supported as they were separate constants. ― A. di M.​_plé​^dréachtaí 20:14, 23 June 2011 (UTC)

Well, in such cases I'd not use the template, or I'd subst it. But that doesn't sound like a good argument to never use such a template at all. ― A. di M.​_plé​^dréachtaí 20:14, 23 June 2011 (UTC)

default ref to yes?

Oughtn't |ref default to yes rather than no? Surely it's better to err on the side of better referencing. --Cybercobra (talk) 22:29, 19 June 2011 (UTC)

 Done. ― A. di M.​_plé​^dréachtaí 20:20, 23 June 2011 (UTC)

Adding another feature

There's a section in the /data page for the uncertainty (unc), however there isn't anything in the template settings to actually give this any functionality. I've only just started dabbling into template coding, could someone give me some assistance with this addition? I (and several other scientists that I have talked to) have agreed that not including the uncertainty would be useful in certain situations. It only needs to be a yes/no parameter similar to the "unit" option. Cheers, Primefac (talk) 03:43, 28 December 2013 (UTC)

How do you define «not included uncertainty»? In the current template documentation, it is defined as «number of digits to round to»; you always have to round, be that to a user-specified value or an automatic one, and not including it sounds paradoxical. Gryllida (talk) 04:19, 28 December 2013 (UTC)

Ah, yes, I see that I have greatly misread the documentation. The "auto" round puts the rounding to the next-digit-up from the uncertainty, meaning that (effectively) "round=auto" removes the uncertainty, which is what I wanted in the first place. Of course, now I have to fix bwien, but that should be a small change. Thank you (even if indirectly) for the help! Primefac (talk) 14:35, 28 December 2013 (UTC)

Expression error: Unexpected < operator

There seems to be a large number of "Expression error: Unexpected < operator" errors in expansions of Template:Physconst, at least for me. I see one in the fine structure constant example of Dimensionless physical constant, and quite a few at Template:Physconst/doc. --82.68.182.45 (talk) 21:36, 8 May 2015 (UTC)

Yeah, I've been trying to figure out the issue (unsuccessfully). There have been almost no edits to this template in the last year, so if I had to guess a template that Physconst is calling somehow got screwed up. Primefac (talk) 21:42, 8 May 2015 (UTC)

Dot multiplied units

Multiplied units like the 'm K' in b = 2.897771955...×10⁻³ m⋅K‍ and the like should be dotted ('m·K') for clarity. Headbomb {talk / contribs / physics / books} 18:17, 16 January 2017 (UTC)

Aye, good call. I'll get on it. Primefac (talk) 18:20, 16 January 2017 (UTC)

References

Relative standard uncertainty feature?

This template currently provides a constant and its standard uncertainty, and provides a central place for updating to the latest CODATA values, reducing maintenance in articles where the latest value is of interest, especially since the footnote generated actually says which CODATA value is provided. Neat. Yet, at times the same articles refer to the relative standard uncertainty. It would be nice for this to be provided through the same template, or a sister/sub template. It could calculate this from the existing data, or it could be entered directly into the template, as with the other values. My instinct would be to use the same template, and to have a flag to control this, just like we can drop the value using the parameter |ref=no. If there is a standard format for expressing a value and its uncertainty using relative standard uncertainty [e.g.: e = 1.6021766340×10⁻¹⁹ C × (1 ± 6.1×10⁻⁹)], this could serve as a guide to doing so, but at least I would like to be able to get something like "u_r(e) = 6.1×10⁻⁹" from it, and similarly for the other constants. Any thoughts on this? —Quondum 20:31, 19 January 2017 (UTC)

References

Quondum, I didn't check every constant, but (to use your example) Elementary charge doesn't mention the relative standard uncertainty (nor do the others I checked). Where is the relative standard uncertainty discussed? Primefac (talk) 22:43, 19 January 2017 (UTC)

I think the question should rather be where would such values be useful. Just search for the phrase "relative standard uncertainty" in WP mainspace. For example, Physical constant, Avogadro_constant and Gravitational constant and many others would benefit from the use of the {{physconst}} template. There was one inconsistency (CODATA2014 values, but with the relative standard uncertainty inconsistent with a CODATA 2010 value) that I've lost now, but would have updated if the template supported that. Looking at Avogadro constant, I see it would be nice to be able to extract the string "2014" using the template, to automatically describe the values provided correctly. —Quondum 00:22, 20 January 2017 (UTC)

@Quondum and Primefac: Speaking of the devil, I just had this problem at Proton-to-electron mass ratio, where someone had the CODATA 2014 value, but the CODATA 2010 uncertainty (0.4 ppb, vs. 2014's 0.095).

Also, if it has been updated to the 2014 values, it might be a nice idea to update the docs to say so. Finally, does anyone know what the "val template issue" which Robin De Schepper installed a workaround for? The edit summary says to undo it when it's resolved, but I don't know what resolution would consist of. 71.41.210.146 (talk) 22:51, 22 January 2017 (UTC)

Interesting. I have no idea what the val issue is (though clearly everything is working). As for the year information - when I last updated the values I updated the reference, so it says "2015" with the accessdate in it. Feel free to add a note to the doc if you really feel it's necessary. Personally I think simply changing "the 2010 CODATA value" to "the CODATA value" in article usage is sufficient.

On a somewhat-related note, I'm sort-of working on a Lua module for this template, which will hopefully eliminate the need for obscenely nested #switch statements. Still fleshing out the overall design, though. Primefac (talk) 22:56, 22 January 2017 (UTC)

71.41.210.146: My example is presumably still lurking out there, since that was not it. As to the {{val}} template issue, the template has been replaced by a LUA version since that note was written, so I have reverted the workaround on the assumption that the issue has been resolved.

Primefac: Simply removing the explicit date as you suggest is fair on a self-updating template given that the supplied footnote gives this CODATA year, though I don't feel that this a great limitation. I still feel that a relative uncertainty value should be available though; there are clearly examples where this would and would be used. —Quondum 02:14, 23 January 2017 (UTC)

Not discounting that option, I'm just not definitely saying "yes we can" because I'm in the process of figuring out where to stick it (if possible) and it might just make the code too convoluted. It's definitely rattling around, though, and I'll keep it in mind as I redesign this thing ;) Primefac (talk) 02:19, 23 January 2017 (UTC)

Thanks. I don't see complexity as an issue (though the switch approach might be distasteful, this will not make it much worse). I see defining the template parameters as the tricky aspect.

Oh, and I see that the generated footnote mentions "CODATA Value" and "June 2015", not "CODATA 2014 recommended values". But that can be fixed easily enough in the template. It is not acceptable to force the reader to the NIST site to figure this out. —Quondum 02:26, 23 January 2017 (UTC)

That's because the |title= of the page is the former, not the latter. The date comes from |date=June 2015, which was when the information was published. Any given reference link does not specifically mention 2014, by the way - you have to go to one of the main pages to see that. The reference gives a suitable level of information. Primefac (talk) 02:45, 23 January 2017 (UTC)

The title is correct, but I'm saying that the reader needs to be able to directly tell which values are being referred to, namely "2014 CODATA recommended values", which NIST displays prominently everywhere. If the footnote does not explicitly give this information, it needs to be made available in another way. I'll try to tweak the footnote and see how you react to the result. —Quondum 03:28, 23 January 2017 (UTC)

I approve of the |quote=. Primefac (talk) 03:46, 23 January 2017 (UTC)

Relative uncertainty - equals?

Should u_r have an = or a ≈ after it? My initial thinking is that if we know the exact uncertainty, that also means we know the exact value, so it should be approximate. Primefac (talk) 23:44, 23 January 2017 (UTC)

I also thought about that. There is no ambiguity about what relative uncertainty means, and hence that if it is nonzero, that it is not an exact value. There is the further conventional implication of the decimal representation that implies accuracy to the least significant digit. The '≈' is only used to stress that the value should not be mistaken as exact, and here this would be more irritation than help. And I don't recall anyone ever using a '≈' for an uncertainty value, so I'd suggest that '=' is conventional. And finally, when the uncertainty is zero, we definitely want '='. So I'd suggest staying with '='. —Quondum 00:12, 24 January 2017 (UTC)

Thoughts for upgrade

Just putting down some thoughts for updating the template and/or making it easier to bug check/update/proof/etc.

1) Change order of switch statements in /doc. In other words, check constant first (main parameter order doesn't need to be changed). This allows all the data for one constant to be in one statement, making it faster to update (no need to visit nine different subsections):

{{#switch: {{{2}}}
 | alpha = {{#switch: {{{1}}}
           | symbol = 
           | val = 
           | etc
 | c
etc

2) Relative uncertainty - put in #if/#switch statement as the first thing to check? This would make it check runc/ref/symbol in that order. Either way, the ref should be included for runc.

Might think of more and add to the list. Feel free to comment on the above. Primefac (talk) 03:31, 23 January 2017 (UTC)

On 1: Yes, that'd be a definite improvement: more maintainable, and just as efficient.

On 2: I think an additional named parameter, default |relunc=no, which if set |relunc=yes omits the units, and replaced val with runc, exp with rexp, and nulls unc. Oh, and round would have to be handled slightly differently, possibly ignored. That is to say, relunc would be checked at the top level, not in the "/data" subtemplate. Otherwise, the template could remain unchanged, including, as you say, keeping the reference. —Quondum 03:56, 23 January 2017 (UTC)

And the symbol X would be replaced by u_r(X). —Quondum 04:08, 23 January 2017 (UTC)

 Done and  Done. Need to finish updating the doc but otherwise I think everyone should be happy. Primefac (talk) 16:42, 23 January 2017 (UTC)

Yes, very neat, thank you. I added in the symbol for standard relative uncertainty. —Quondum 23:08, 23 January 2017 (UTC)

Does it make sense to have a |symbol=only option, for example, to produce only the string u_r(m_e)? —Quondum 23:21, 23 January 2017 (UTC)

Not really. It's just text, and won't be updated when the template is updated. Primefac (talk) 23:23, 23 January 2017 (UTC)

I came to the same conclusion initially, but I thought of a context where the user of the template is actually another template writer who wants to put together the different bits in a different format (e.g. constructing a sentence or table). But I guess that there is an argument to avoid complexity in templates that might never see use. —Quondum 00:18, 24 January 2017 (UTC)

Just how standard is this u_r(m_e) notation? I've never seen that ever. Normal notation would be Δm_e = ... % or similar. Headbomb {talk / contribs / physics / books} 01:37, 24 January 2017 (UTC)

It was taken from "Standard Uncertainty and Relative Standard Uncertainty". The NIST Reference on constants, units, and uncertainties: Fundamental physical constants. NIST. The notation Δm_e seems to be decidedly informal and even then would at best refer to standard uncertainty and not to relative standard uncertainty; in any event it normally means a difference, which is something else entirely. I've seen the notation u_r in print, e.g. [1], but not often. Failing a better reference, I'm happy to go with NIST. —Quondum 02:36, 24 January 2017 (UTC)

round=auto values

The documentation reads

If set to auto, the value is rounded so that the standard uncertainty is no more than 1.5 units in the last place.

I interpret this to mean that a value y ± u(y) (where, as per NIST, u(y) denotes the standard uncertainty) would be rounded such that a 1 in the least significant decimal digit has a value d such that 0.15d < u(y) ≤ 1.5d. Example: the fine-structure constant α is rounded to 7.29735257×10⁻³, and d = 1×10⁻¹¹. Here, 0.15d = 0.15×10⁻¹¹, u(α) = 0.17×10⁻¹¹ and 1.5d = 1.5×10⁻¹¹, which satisfies the inequalities, so this rounding is correct. For others, the first inequality is not satisfied and an extra digit seems to be appropriate, namely for e, eV, F, h, ħ, m_e, m_u, N_A, Φ₀ and σ. Am I missing something? —Quondum 03:32, 24 January 2017 (UTC)

I think you might be. Let's look at e: value is 1.602 176 6208, standard uncertainty is 0.000 000 0098. For ease of reading just at the last five digits (66208 and 98). 1.5×98 is 147. 66208 ± 147 = {66335, 66061} Thus, the most accurate we can get is to have the 6 (making it 1.602 1766 as listed); we can't have the 2 because the uncertainty could lead that digit to being anywhere between 1 and 3. I'll double-check all of the values as presented, though. Primefac (talk) 15:01, 24 January 2017 (UTC)

You are using a different criterion than the stated criterion. The stated criterion allows the least significant digit to vary over three values between one-sigma limits, as you have found. I think that is a pretty good tradeoff between throwing away known accuracy and including inaccuracy in the displayed value. —Quondum 16:16, 24 January 2017 (UTC)

After some discussion, I propose we change the wording to

If set to auto, the value is rounded so that the standard uncertainty is no more than 0.5 units in the last place.

I'll go through the rounding figures to match this description at some point; if they mismatch, we can consider adjusting the description. —Quondum 22:30, 26 January 2017 (UTC)

Can I wrangle in some other opinions from WP:PHYS first? You got three responses, and only one "agreed" with your 0.5 value. I'm not trying to be an ass about this, but I really think something like this should see as much input as possible. Primefac (talk) 22:46, 26 January 2017 (UTC)

By all means; I'd be interested in your take on this, either here or there, and any reactions you get. I did not get any responses inconsistent with the value 0.5, but there is room to argue about the value. My take on your rounding values is that you like a value in the range 0.1 to 0.2. If you expect the range x±δ to always include 50% or more of the uncertainty distribution, k = 0.5 is about the smallest value that does not become completely weird. Take k = 0.1 with 0.444±0.001 as an example. Rounding this as 0.44 implies 0.0001≤u≤0.001, but 0.44±0.001 does not overlap the original value at all. Rounding it as 0.4 implies 0.001≤u≤0.01, but 0.4±0.01 again does not nearly overlap the original value. At k = 0.5, we'd round this to 0.44, implying 0.44±0.005, which at least contains the original value.

Incidentally, I see the #expr:round processing does not keep the trailing zeros appropriate to this context: rounding to 5 {{#expr: 0.12356789 round 5}}→0.12357 but {{#expr: 0.10000000 round 5}}→0.1. Do you know how to fix this? —Quondum 00:03, 27 January 2017 (UTC)

To answer your very last question - no I do not.

To answer the rest - I need more sleep before responding. However:

in my sleep-addled stupor, I decided to create Template:Physconst/roundtest. At the moment it shows the difference between 0.5, 1, and 1.5×unc. The intention, after we get the above sorted out, is to provide a check post-CODATA-update to ensure the rounding number is still accurate or if it needs adjusting. Primefac (talk) 01:35, 27 January 2017 (UTC)

Go for it. I've crunched a stupid amount of numbers and you're right. I'll update the rounding check later today and adjust the rounded values accordingly. Primefac (talk) 16:07, 27 January 2017 (UTC)

un1 and round updates

I've added the |un1= parameter in the /data subtemplate, which seems to work better for the #expr calculations we are using, implied by the |round= functionality. The intention is to replace the existing |unc= parameter of /data. This means deriving the digits to put in parentheses, e.g., mapping 0.00019 to (19) when there are five significant digits after the point of the value. —Quondum 02:07, 5 February 2017 (UTC) Also, I think we should be able to calculate the round=auto case, and so eliminate the |round= from /data, making it less confusing to enter new constants. Does this make sense? —Quondum 02:15, 5 February 2017 (UTC)

I fully appreciate the addition of adding un1, but I think removing unc is going to cause more problems than it solves. This is already a fairly labour-intensive template (just in "normal" use with no extra parameters it makes four calls to the /data and twice that many #if/expr/round calls), and making it do a complicate find/trim/replace just to save one line of /data code is unnecessary.

As for automatically creating the round - that's not really feasible unless we shift this to a module. Again, there's no harm in having one line of text that we occasionally have to update (plus, with at least two people watching this page, new added values can be checked by other users).

So... I agree with the changes you've made so far, but I disagree with the rest, mainly in the interest of not making a complex template more complex. Primefac (talk) 02:35, 5 February 2017 (UTC)

Fair enough. My primary intention is to avoid the potential for confusion and error created by redundant parameters in /data. As long we can put together the /data/disp subtemplate to complain when there is an inconsistency, then we can produce the simplest possible template physconst without concern for error. Since un1 is not used in the main template, I'll look at a better way of implementing the checks without it; the main problem was that the templates were not cooperating (which is a euphemism for me being unable to get them to work). I assume that complexity of the /data/disp subtemplate is a non-issue, since its only use is to run a check on the template. —Quondum 03:23, 5 February 2017 (UTC)

Nonstandard presentation of a few constants by NIST

I don't have any strong feelings about the presentation of the CODATA values, but we should probably figure out why NIST has the weird choice of placement of the decimal point for a few of the constants if we are going to be particular about it, otherwise it is a bit like insisting on using the some font as the original. Maybe a question for WP:RD/S? —Quondum 20:18, 27 January 2017 (UTC)

I have left an e-mail with one chap and a phone message with another, so hopefully by Monday we'll know why NIST has some odd decimal choices, though I suspect its because values like m_p/m_e or α⁻¹ are ratios of other known numbers, and changing their decimal point could potentially be construed as a higher(/lower?) level of accuracy. Obviously we can do whatever we want on-wiki, so I suppose a note at RD/S might be worthwhile while we wait. Primefac (talk) 22:16, 27 January 2017 (UTC)

We do not seem to have advanced much here. I am happy with two formats that NIST uses: when the exponent is set to zero and the "×10⁰" is dropped, and normalized scientific notation. Non-normalized scientific seems weird, but is used for isolated cases, one of which (magnetic constant) I see a rationale for. I see no implications on construed accuracy. —Quondum 19:07, 4 February 2017 (UTC)

You do what you feel is best. While I'm sure there is a reason for having non-standard presentation of some values, not having that reason is sufficient enough reason to go with consistency. If and when I turn up that reason (if it jives) I'll make my case. Primefac (talk) 02:43, 5 February 2017 (UTC)

Finally got a response from NIST:

Hi,

Scientific notation is typically used to represent very large or very small numbers.
Decimal notation is usually preferred.
Many of the constants are written using decimal notation

Inverse fine structure  137.035 999 139
Speed of light  299 792 458 meters (exact)
Rydberg constant  10 973 731.568 508
Faraday constant  96 485.332 89
Gas constant  8.314 4598

By analogy
It is 3,944 kilometers from LA to NY, not 3.944 10^5 meters.
A millimeter is 0.001 meters, not 1.0 x 10-3 meters.

Hope this helps.

Looking over our values, this makes sense why some values (that are in the tens of thousands of metres) are written as such. Thus, I am still of the opinion (now backed up by the actual people who record the numbers) that we should leave the numbers as found on the NIST site. Primefac (talk) 19:27, 22 February 2017 (UTC)

Planck mass has a wrong unit

Hi, I have just noticed that Planck mass has a wrong unit : it is expressed in kg-1 instead of kg! Could someone correct it ? Loj19 (talk) 15:32, 18 July 2017 (UTC)

 Fixed. Thanks. Primefac (talk) 19:11, 18 July 2017 (UTC)

Discussion of CODATA 2017 values

The CODATA 2017 special release was made 2017-10-20, providing updated measured values for h, k, e, and N_A, and the exact values to be used in the redefinition of SI this November. This is an official CODATA TGFC publication, but a partial one. There's a discussion going on at WP Talk:WikiProject Physics about whether to incorporate those values here.

Of particular note, although the CIPM has incorporated the proposed values into the Draft Resolution A it officially voted to forward to the CGPM (and the CGPM will almost certainly rubber-stamp), the paper linked above is still officially a preprint. And the final measured values (with uncertainties) are very short-lived, to be replaced by exact values when the redefinition goes through. Thus, its status is a bit unusual. 23.83.37.241 (talk) 22:48, 27 January 2018 (UTC)

round=auto take 2

This is a follow-on from the discussion round=auto above. We seem to have hit on a formulation for choosing auto round values that has really weird unintended effects depending on the value being rounded. I propose revising the criterion to simply being as originally stated: that the number of digits for auto rounding of a value x is determined by only the standard uncertainty u(x) and not by x itself, specifically such that the number of digits r after the decimal point for auto rounding is chosen as the largest such that u(x) ≤ 0.5 × 10^-r (As per the documentation: "If set to auto, the value is rounded to the most digits such that the standard uncertainty is no more than 0.5 units in the last place.") Having the value communicate the standard certainty within an order of magnitude is far more important than the actual value being within the inferred range. I'm pretty sure the values for auto-rounding as I set them with the last adjustment are correct now by this criterion, but the check at Template:Physical constants/data/doc is all over the show. —Quondum 12:50, 25 May 2019 (UTC)

Um... that's exactly what we're currently doing. The round values are just off because the values all changed without the rounding being appropriately adjusted. Primefac (talk) 16:01, 29 May 2019 (UTC)

I disagree. I'm saying that the interpretation on {{Physconst/data/doc}} (i.e. ${\text{val}}_{\text{round}}\pm {\text{un1}}>{\text{val}}\mp (0.5*{\text{un1}})$) depends on val, not only on un1. We should always have round = ceil(log₁₀(0.5/un1)), unless un1 is zero. Take a simple example: 1.00000 ± 0.00004. I say round = ceil(log₁₀(0.5/un1)) = 4, making the display value 1.0000, as we would expect. But with the calculation as is, what would you get? As far as I can tell, the inequalities are satisfied for any value of round, since val_round = val is true for every round ≥ 0. —Quondum 01:40, 30 May 2019 (UTC)

Just a thought

Okay, I was writing out a reply to the above comment starting with "I disagree" but got a little sidetracked (twice), but I just set up a tracking category just out of curiosity to see how many pages even used the auto-rounding. So far nothing. Do we even need to worry about auto-rounding? Primefac (talk) 15:42, 5 June 2019 (UTC)

There were two, and I removed one because the rounding related to values that have become exact. Only one page now uses |round=auto: Gravitational constant. But I agree with your point: this feature is hardly worth worrying about the auto rounding choice. It potentially even makes sense to remove the 'auto' option. —Quondum 16:16, 5 June 2019 (UTC)

@Quondum and Primefac: I agree that the documented inequality is messed up and makes no sense. (The fact that there are constants for which the test table shows green/red/green shows something is wonky.) Either the equation and its implementation in Template:Physical constants/data/disp needs to be updated to match the text, or the text needs major revision.[2] I tried to do the latter, but couldn't make head or tail of the equation. ${\text{val}}_{\text{round}}\pm {\text{un1}}>{\text{val}}\mp 0.5\times {\text{un1}}$ is equivalent to ${\text{val}}_{\text{round}}-{\text{val}}>\mp 1.5\times {\text{un1}},$, which is always false in the 50% of cases when ${\text{val}}_{\text{round}}<{\text{val}}.$ Is is supposed to be $\left|{\text{val}}_{\text{round}}-{\text{val}}\right|>1.5\times {\text{un1}},$ perhaps? 167.88.12.231 (talk) 09:00, 7 June 2019 (UTC)

The language in gravitational constant was dumb when related to the auto-round, so I just set it as a hard limit. If no one is strongly opposed I'm going to just nix the param altogether. If we do keep it, I think you're right as far as the absolute value goes. However, I think converting to a module or something to automatically calculate the round value is a better way to go, since it's kind of stupid to have to "guess and check" with the proper rounding value every time the data gets updated/changed. Primefac (talk) 10:30, 7 June 2019 (UTC)

I'm good with nixing the parameter. And yes, if retained, an auto-calculation would make sense, but this would involve either an ad-hoc choice for the formula or a good understanding of what is "meant" by any particular choice of rounding precision. As an aside, this is not a trivial problem, since rounding a value that has an uncertainty distribution is akin to double rounding, and we are additionally burdening the resulting representation with encoding the uncertainty interval. 167.88.12.231, yes, the wikiquote is food for thought; in this case it means that we have not properly understood the problem. I'm happy to debate assigning a precise "meaning" to a rounded value as a point of interest, though its applicability in the context of this template seems moot. —Quondum 12:44, 7 June 2019 (UTC)

I also support removing the "auto" parameter. I found this discussion after noticing it "rounds" Avogadro's constant to the same number of digits as the original—and that number is now exact, while the "auto" option erroneously shows ≈ rather than =. Rather than fixing these issues, it probably makes more sense to cut out this unneeded option. Benny White (talk) 04:54, 9 June 2019 (UTC)

Primefac, thank you for cleaning up the template. This is a definite simplification. —Quondum 19:21, 9 June 2019 (UTC)

Removal of "CODATA 2018" indication

@Headbomb: with this edit, the visible indication that it is the CODATA 2018 value has been removed. We felt that this indication was useful to the reader – please see the last four posts of Template talk:Physical constants/Archive 1 § Relative standard uncertainty feature? I would prefer to retain this indication, though it does not have to be in the form that it was. —Quondum 13:19, 16 June 2019 (UTC)

My main objection is that this is not a quote. I feel the |date=20 May 2019 makes it clear that this is the most recent value as of 2019, but if it needs to be made clear that this is based on the '2018 recommended values', then there's a number of ways to do that, like

"2018 CODATA Value: Bohr radius". The NIST Reference on Constants, Units, and Uncertainty. US National Institute of Standards and Technology. 20 May 2019. Retrieved 2019-05-20. 2018 CODATA recommended values {{cite web}}: Cite has empty unknown parameter: |month= (help)

instead of

"CODATA Value: Bohr radius". The NIST Reference on Constants, Units, and Uncertainty. US National Institute of Standards and Technology. 20 May 2019. Retrieved 2019-05-20. 2018 CODATA recommended values {{cite web}}: Cite has empty unknown parameter: |month= (help)

Headbomb {t · c · p · b} 14:27, 16 June 2019 (UTC)

I'll assume that you meant to omit the |quote=2018 CODATA recommended values from your suggestion. I tried to follow the principle of exactness, as you seem to want to do. It would still be fair to say that "CODATA Value: Bohr radius" is the title (that is what appears in the tab of the browser) and "Source: 2018 CODATA recommended values" (or indeed "2018 CODATA recommended values") is technically a quote from the page (it appears in the lower-left corner), even though it use is unusual, not highlighting the point of interest. I prefer the briefer, simpler approach of your suggestion even though it is not an exact copy of the title (for clarity, without any |quote=). I did not do this before, I guess, to sidestep the need to discuss it to gain consensus. We could also abbreviate |publisher=US National Institute of Standards and Technology to |publisher=NIST. This would give:

"2018 CODATA Value: Bohr radius". The NIST Reference on Constants, Units, and Uncertainty. NIST. 20 May 2019. Retrieved 2019-05-20.

—Quondum 15:17, 16 June 2019 (UTC)

Looks fine by me. Headbomb {t · c · p · b} 15:21, 16 June 2019 (UTC)

@Primefac: Your opinion? I would be happy to make the change. —Quondum 16:19, 16 June 2019 (UTC)

 Done. Primefac (talk) 02:41, 17 June 2019 (UTC)

Rounding of values

@Primefac: I do not disagree with your rationale on your revert (the value displayed without rounding should be as per the source). However, the issue of correct rounding lies with the template as a feature it provides and should give a correct result, so if an editor selects |round=5 in this example, it should round up. This means that additional template data is needed for rounding at the last digit of the full available precision (useful primarily where the value is exact). Thoughts? —Quondum 14:58, 22 October 2019 (UTC)

We should give what the sources provide. If CODATA truncates instead of rounds, then we should truncate instead of round. Primefac (talk) 23:34, 22 October 2019 (UTC)

That was not what I was saying. The following we will agree on, but is not correctly described as truncation:

{{physconst|RK|symbol=yes}} → R_K = 25812.80745... Ω‍

But the following is not what this source gives:

{{physconst|RK|round=5|symbol=yes}} → R_K ≈ 25812.80745 Ω‍

Under this condition, we can rely on WP:CALC to determine the correct rounding as R_K ≈ 25812.80746 Ω, determined from authoritative sources (i.e. the 9th SI Brochure). —Quondum 00:03, 23 October 2019 (UTC)

Sure, we can change the ref, but if the source has a value ending in 5, we need to end the value in 5. Primefac (talk) 14:23, 1 December 2019 (UTC)

Our choice of truncation or rounding is not bound by 'sources'. That would be insane to not be able to round because a source truncates, or not be able to truncate because a source rounds. Headbomb {t · c · p · b} 16:32, 1 December 2019 (UTC)

I don't disagree, but if a source only gives a final digit of 5 (without showing the next digit) we cannot make that determination about how to properly round. Primefac (talk) 16:35, 1 December 2019 (UTC)

Again, we are not bound by sources for how to round or truncate. That is our choice. Headbomb {t · c · p · b} 16:41, 1 December 2019 (UTC)

And again, I'm not disagreeing with you. However there is no way that we can currently make the template so if |round=5 then it shows 25812.80746 but if the "raw" value is given it shows 25812.80745..., the latter of which is supported by the given reference. Primefac (talk) 17:05, 1 December 2019 (UTC)

You're both correct, pretty much. We cannot round the source's data by removing the dots: the source simply lists the digits up to some level, then adds dots to show there are more digits, and this gives sufficient information to truncate, not to round, but the template claims to round. Here is a proposal: if |end= is not empty and the selected |round= is greater than or equal to the provided number of digits, display an error message. —Quondum 05:20, 2 December 2019 (UTC)

References

As I was writing the above reply (but I'll keep it on its own for separated replies) I have to wonder the "what's the point?" question; if the "raw" value is 25812.80745, why would anyone set |round=5? Are we trying to fix a nonexistent problem? Primefac (talk) 17:07, 1 December 2019 (UTC)

Indeed, a reasonable question. Because they don't want the dots? Because they are adding the figure in a table of rounded figures where that level of rounding is appropriate, and having the dots would be out of place in the context? Nevertheless, if there is a simple way of avoiding producing an unnoticed error (which this would be, to a nitpicker), is it not worthwhile doing remedying this? —Quondum 05:20, 2 December 2019 (UTC)

Coulomb Constant

@Ahri6279 and Quondum: is there a ref for k_e? I've only done a quick check of NIST but I don't see it. Primefac (talk) 19:12, 11 March 2020 (UTC)

No, I do not believe that it is on the NIST site. I calculated the value from k_e = 1/4πε₀ using NIST's CODATA value and relative uncertainty for ε₀. This is why I did not give a reference in the template data. —Quondum 19:57, 11 March 2020 (UTC)

I'm regretting that I pre-emptively added to this edit. Perhaps we should make the purpose of the template clearer, for example: is it intended that it provides the latest CODATA values (as intimated in the template docs), physical constants derived from CODATA values, or something else? I do not recollect seeing a mention of the Coulomb constant by this name in reliable sources with any frequency, to the point that I wonder how notable this name is. (I confess I previously included Z₀ in a similar way, but this was partly because it had had been on the NIST site before.) If we define the template purpose more clearly, the choice of whether to include any specific constants would be simpler. —Quondum 17:42, 5 April 2020 (UTC)

I think if it's not on NIST then it probably shouldn't be in the template; if we're doing a big calculation like the one above, the error also needs to be calculated, and then we're into "not so straight-forward calculation" territory bordering on WP:OR. Primefac (talk) 21:29, 5 April 2020 (UTC)

I'm confident enough of the calculation, including error, that I feel it fits the definition of WP:CALC – I got it nailed down pretty well last time. But if you're happy to define the template as providing the most recent CODATA values and nothing else (up to an update lag), I'll tweak the wording of the template doc to make this intent clearer, and then I'd be happy for k_e to be removed (the only article affected is Coulomb constant, so removing all references is simple). —Quondum 23:59, 5 April 2020 (UTC)

Okay, all done. I will leave it to you to jettison the non-CODATA value if you wish to. —Quondum 02:17, 6 April 2020 (UTC)

Standardisation of notation

The unit given for the speed of light is m/s, not m⋅s^-1. Can this be changed? Plokmijnuhby (talk) 07:20, 24 August 2020 (UTC)

Reasonable. Done. Primefac (talk) 10:22, 24 August 2020 (UTC)

A place for exact values

Several of these constants are set by convention rather than measured and thus can be computed and presented to arbitrary precision (WP:CALC). In particular, I see value in providing ~20 digits so that software can use the most accurate value representable in double-precision floating-point format. I put in those digits but they were undone by @Primefac, who noted that the cited sources do not provide those digits. I'd like to provide the higher-precision values somehow; perhaps we could add a new field for them. However, I am unsure how other pages would make use of the new field. Or, maybe different approach would better achieve the desired ends. What do you think? —Quantling (talk | contribs) 17:04, 10 February 2021 (UTC)

Calculated or not, we can only really use what the sources say. If the references only give six sig figs, then we only report six. Additionally, I see little use in providing a number as long as 1.00000008887143810491801; after a certain point the precision becomes trivia rather than useful. Primefac (talk) 19:01, 10 February 2021 (UTC)

We are permitted to do simple math to build on what the sources tell us according to WP:CALC. I am thinking that the likes of dividing a provided value of h by 2π is pretty simple. The example of 1.00000008887143810491801 is the one case where the decimal expansion is both finite in length and longer than 20 digits, so I broke my template of using just 20 digits for that one case in order to give the exact value. I am hopeful that there is a place in Wikipedia where full double-precision values can be supplied, and would appreciate your help in deciding where that should be. —Quantling (talk | contribs) 23:04, 10 February 2021 (UTC)

Sure, we can do simple calculations using a {{#expr...}} or similar, but when it comes to this particular template, it provides a value and a reference. If the value does not match the reference, then we are not doing it properly. If there are instances where the full/extended/etc value is needed, then an #expr may be the best way to go. Primefac (talk) 13:22, 12 February 2021 (UTC)

My reading of WP:CALC is that, for example, if a source says that there are 2 blue cats and 3 red cats and no others then we can give that source in a citation for a sentence that says "There are 5 cats". Please let me know if you disagree. Or more to the point, please let me know if you think the likes of the calculation of h/2π is too complicated to qualify for WP:CALC. If you are worried about the accuracy of these double-precision values and are unsure how to check them yourself, I could make and give you a script in R (or maybe bc); would that help? On other fronts, is it that you find the additional digits to be unsightly or otherwise a negative for the reader? —if so, please give details. Thank you —Quantling (talk | contribs) 18:51, 12 February 2021 (UTC)

I know how to calculate h/2π, I conveniently have a degree in physics. I don't find any issue with the accuracy of your edits, but I find them unnecessarily detailed, especially for something like A₉₀. We are an encyclopedia designed to provide summaries of values. We can tell people that to A₉₀ = (K_J-90R_K-90/K_JR_K)A (the majority of those values being complex equations themselves), or give them the truncated value provided by NIST, but we're not doing calculations with these values so the precision of 1.00000008887143810491801 is just simply too much; it doesn't mean anything. The folks that are using these full values likely are using the root equations (and wouldn't be checking Wikipedia for the value anyway), so a half-dozen truncated digits are more than sufficient for the lay-person. Primefac (talk) 11:34, 13 February 2021 (UTC)

Yes, calculating h/2π with a double-precision calculator is easy for pretty much anyone. I apologize that my comments came across as otherwise—my offer of R code is because that supports extended-precision arithmetic with its Rmpfr package, with the obvious benefit of computing even the least-significant of the 20 displayed digits correctly. Maybe that's my naïveté; maybe pretty much everyone has access to extended precision these days.

Would you be okay with my adding an additional field called something like valprecise that would have the WP:CALC'ed value with many more digits? We would enable editors of other pages the option of using it where consensus deemed it appropriate. (Obvious disclaimer: I could be such an editor.) Many people writing computer programs would appreciate the extra precision if it is easily available. And yes, mission critical folks would want to verify the numbers independently, but would find Wikipedia to be a nice sanity check. Thank you —Quantling (talk | contribs) 17:02, 13 February 2021 (UTC)

Quantling, I don't think it is a good idea. Wikipedia is an encyclopedia, not a scientific handbook. It is not a source for ultra-precise values for researchers; they will use accepted scientific references. And given the trickiness of numerical precision in computing they will let the software calculate the value of the Josephson constant from the easier to enter values of e and h themselves. This template was set up to make it easy to keep the CODATA values, and just those values, used in articles up to date. It needs to provide the values given in the source. StarryGrandma (talk) 00:52, 14 February 2021 (UTC)

It is a shame that this template isn't named "Template:CODATA values" because that would make it easier for me to understand the fixation on the values from that one source. Making high-precision values available via template would not require that they be used in any particular Wikipedia article. The editors of those articles would decide whether they were appropriately encyclopedic on a case by case basis. —Quantling (talk | contribs) 19:13, 15 February 2021 (UTC)

You're welcome to discuss changing the source on one or more of these values (and as a result the value), but given that NIST are one of the main bodies that define these values, it will probably need some discussion. Primefac (talk) 21:56, 15 February 2021 (UTC)

Changing the source from CODATA isn't what I had in mind. The CODATA source provides the fundamental constants exactly and simple CALCulations give us the values of the exact, derived constants to any precision we want, such as would be useful in a piece of software employing the usual precision. I am trying to get consensus on using simple calculations based upon the CODATA fundamental constants. —Quantling (talk | contribs) 01:00, 18 February 2021 (UTC)

I see a number of points to consider here, made all the trickier by this being a template.

• Whatever the template name is (sort of irrelevant, though a renaming is not out of the question), it currently does provide CODATA values with the source. If it were to allow for presenting another kind of value (e.g. arbitrary precision based on assumed relationships), we would have to suppress the source footnote when used this way.
• If we cannot find authoritative references that give extended precision, this would seem to suggest that WP should not buck that trend. It looks too unprofessional (already editors put in too much non-encyclopaedic material) if we present more than any sources do.
• The theoretical expressions might be assumed to be exact, but understanding of physics is not where we can say that they are with certainty. For example, the metrology triangle (essentially measuring the elementary charge directly and calculating it from K_J and R_K) is a crosscheck of such a case, and in principle could find a discrepancy as precision of measurements increase. This would suggest that we need to stick to the sources and not use the assumed formulae to be correct.
• The presentation of ultra-precision values is a per-article choice (and hence not for template-providers to decide on). This would suggest that there is no reason not to provide a special mode of the template with ultra-precision other than that it might be seen to encourage its use (a concern). Nevertheless, I see this as being an exceptional use, and as such it probably makes sense for the editors of the article concerned to use an exceptional calculation method rather than extending the template for this.

At best, this not a simple extension of the precision of the values in the template data: it would be a template rework. On balance, I don't like the idea of giving editors the impression that selecting arbitrary precision is the norm. I'm pretty sure it would be abused. —Quondum 15:23, 18 February 2021 (UTC)

Given that Wikipedia does permit simple CALCulations, I worry that people who are arguing against these calculations here consider them to not be simple. Here is R code that can be run on your own computer or via a web service (such as this one):

 library(Rmpfr)
 bits <- 1000
 
 # Fundamental constants
 atm <- mpfr("101325", bits)
 c <- mpfr("299792458", bits)
 DnuCs <- mpfr("9192631770", bits)
 e <- mpfr("1.602176634e-19", bits)
 g0 <- mpfr("9.80665", bits)
 h <- mpfr("6.62607015e-34", bits)
 k <- mpfr("1.380649e-23", bits)
 KJ90 <- mpfr("483597.9e9", bits)
 Na <- mpfr("6.02214076e+23", bits)
 RK90 <- mpfr("25812.807", bits)
 
 # Useful numbers
 Pi = 4 * atan(mpfr("1", bits))
 
 # Derived constants
 KJ <- 2 * e  / h
 RK <- h / e / e
 V90 <- KJ90 / KJ
 assign("V90 - 1", V90 - 1)
 Omega90 <- RK / RK90
 assign("Omega90 - 1", Omega90 - 1)
 A90 <- KJ90 * RK90 / KJ / RK
 assign("A90 - 1", A90 - 1)
 C90 <- KJ90 * RK90 / KJ / RK
 assign("C90 - 1", C90 - 1)
 W90 <- KJ90 * KJ90 * RK90 / KJ / KJ / RK
 assign("W90 - 1", W90 - 1)
 F90 <- RK90 / RK
 assign("F90 - 1", F90 - 1)
 H90 <- RK / RK90
 assign("H90 - 1", H90 - 1)
 x <- mpfr("5", bits); repeat{xold <- x; x <- x - ((x - 5) * exp(x) + 5) / ((x - 4) * exp(x)); if (x >= xold) break;}; x5 <- x; rm(x, xold)
 x <- mpfr("4", bits); repeat{xold <- x; x <- x - ((x - 4) * exp(x) + 4) / ((x - 3) * exp(x)); if (x >= xold) break;}; x4 <- x; rm(x, xold)
 x <- mpfr("3", bits); repeat{xold <- x; x <- x - ((x - 3) * exp(x) + 3) / ((x - 2) * exp(x)); if (x >= xold) break;}; x3 <- x; rm(x, xold)
 x <- mpfr("2", bits); repeat{xold <- x; x <- x - ((x - 2) * exp(x) + 2) / ((x - 1) * exp(x)); if (x >= xold) break;}; x2 <- x; rm(x, xold)
 bwein <- h * c / k / x5
 assign("bwein'", k * x3 / h)
 c1 <- 2 * Pi * h * c^2
 c1L <- 2 * h * c^2
 c2 <- h * c / k
 eV <- e
 F <- Na * e
 G0 <- 2 * e^2 / h
 hbar <- h / 2 / Pi
 invG0 <- h / 2 / e^2
 NAh <- Na * h
 Phi0 <- h / 2 / e
 R <- Na * k
 sigma <- 2 * Pi^5 * k^4 / 15 / c^2 / h^3
 
 for (var in setdiff(ls(), c("bits", "var"))) { cat(sprintf("%11s = %s\n", var, format(get(var), digits=105, scientific=TRUE))) }

Does that help? —Quantling (talk | contribs) 14:05, 19 February 2021 (UTC)

This is not about the simplicity of performing these calculations, so I'm honestly flummoxed as why you keep trying to tell us how easy it is to perform these calculations. Primefac (talk) 14:13, 19 February 2021 (UTC)

I fail to see the appropriateness/motivations of a template that provides such values, as indicated in my previous post. At best this debate should be about inclusion of such values in a specific article. The motivation "Many people writing computer programs would appreciate the extra precision if it is easily available" seems to me to be out of scope of WP, and using WP as a check on precision details, no matter how cursory, is just not what WP is for. It is neither a textbook nor a workbook of worked problems. It seem clear that multiple people have concerns that updating the template in this way does not fit the purpose of WP. —Quondum 15:18, 19 February 2021 (UTC)

Try as I might, I cannot convince you fine souls of the utility and appropriateness of these values in this template, and thus there is cause for me to reconsider. Thank you for your time and feedback. —Quantling (talk | contribs) 20:29, 20 February 2021 (UTC)

Formatting dates?

I am working on bringing Nucleon magnetic moment to "Good Article" status. The reviewer notes that the date formats to some of the article citations are inconsistent... Some of these citations are from this template, which seems to insist on DD MM YYYY. Is there an option with this template for the date format? Bdushaw (talk) 11:46, 10 December 2022 (UTC)

Never mind...I've learned the joys of the {{use mdy dates}} template. Perhaps the description could indicate that template? Bdushaw (talk) 12:42, 10 December 2022 (UTC)